This is important for clients to know the point from which it is safe to load state without
risking problems due to the e2ee machinery not being ready yet.

… before connecting to the server

This allows libQuotient-based clients to operate with the cached state (and in the future, room events)
when there is no network connection. It's losing the check whether userid and deviceid correspond to the given token,
but I don't see a strong need for that.

Linux pipelines fail mysteriously since the rewrite, with the keychain
job getting deleted before yielding the result - maybe the newest
Qt Keychain would be better?

Qt 6.4 doesn't handle QFutures with move-only results well.
The workaround for now is to pass the reference to the ultimate
move-only result (i.e. Connection::Private::encryptionData) into
all the continuations as a captured variable. Once we require
at least Qt 6.5 this workaround can be removed and normal QFuture
logic used to pass defered results around.